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REMARKS 

Reconsideration of the application in light of the following remarks is respectfully requested. 
Status of the Claims 

Claims 1 and 15 have been amended to provide that "the fault tolerance, the load balance 
and the failover are performed transparently." No new matter is added. Support for the amendment 
to claims 1 and 15 can be foimd in the Specification at, generally, page 8, lines 21-23 and page 10, 
lines 17-19. Claims 9 and 14 have been amended to be consistent with the changes to claim 1. 
Further, new claims 23 and 24 have been added to provide protection for load balance along and in 
combination with failover. 

Claims 1-24 are pending. 
Allowable Subject Matter 

Applicants thank the Examiner for indication that claims 3-8 and 1 1 contain allowable 
subject matter and objecting to them only based on their dependence on a rejected base claim. 

Allowable claim 3 has been rewritten into independent form, in accordance with the 
Examiner's suggestion. Applicant submits that amended claim 3 and its dependant claims 4-8 and 
1 1 are now in condition for allowance. 

Rejections Under 35 U.S.C, SlOl 

Claims 1-22 stand rejected under 35 U.S.C. §101 as being directed to non-statutory 
subject matter. In particular, the Examiner contents that the claims are directed to method steps, 
which can be practiced mentally in conjunction with pen and paper, therefore they are directed to 
non-statutory subject matter. The Examine specifically cites MPEP 21061 [sic. 2106] in support of 
his positon. However, a search of this section of the MPEP fails to find any support for the 
Examiner's position and in view of State Street Bank & Trust Co. v. Signature Financial Group 
Inc, 149 F.3d 1368 (Fed. Cir. 1998), such a rejection cannot be maintained where the process is 
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novel and provides a useful, concrete and tangible result. As noted in Musco Corp. v. Qualite, Inc., 
41 U.S.P.Q.2d 1954, 1961 (Fed. Cir. 1997) the "existence of mental steps in the claims or 
specifications of a patent do not, in and of themselves, invalidate the patent. But where, as here, the 
claimed subject matter ... is composed solely of mental steps, at the very least, some aspect of these 
mental steps must be non-obvious, and the specification must describe this same aspect so as to 
enable the skilled artisan to practice the invention." Thus, at most, "mental steps" is a basis for a 
rejection under section 102, 103 or 112, not section 101. Nevertheless, in accordance with the 
Examiner's recommendation, independent claims 1 and 15 have been amended to include the term, 
a " computer implemented method ", to clearly indicate that a computer is utilized in the claimed 
method. 

Rejections Under 35 U.S.C, S103(a) 

Claim 1 stands rejected imder 35 U.S.C. § 103(a) as being unpatentable over U.S. 
Patent No. 6,209,018 to Ben-Shachar et al. ("Ben-Shachar"). Claims 2 and 9 stand rejected as being 
unpatentable over Ben-Shachar in view of "JR (Java Reflective Broker)". Claims 10, 12 and 13 
stand rejected as being unpatentable over Ben-Shachar in view of Amo. Claim 14 stands rejected as 
being unpatentable over Ben-Shachar in view of "Geoffrey (The Gateway system: Uniform Web 
Based Access to Remote Resource)". Claims 15 and 16 stand rejected as being unpatentable over 
Ben-Shachar in view of U.S. Patent No. 5,675,795 to Rawson et al. ("Rawson") and U.S. Patent No. 
5,452,447 to Nelson et al. ("Nelson"). Claim 17 stands rejected as being unpatentable over Ben- 
Shachar in view of Rawson and JR (Java Reflective Broker). Claims 18 and 19 stand rejected as 
unpatentable over Ben-Shachar in view of Rawson, Nelson and Amo. Additionally, claims 20 and 
21 stand rejected as being unpatentable over Ben-Shachar in view of Rawson, Nelson and U.S. 
Patent No. 5,742,759 to Nessett et al. ("Nessett"). 

With respect to claim 1, the Examiner contends that Ben-Shachar discloses all of the 
features of claim 1, except the term appending a cluster. However, the examiner contends that Ben- 
Shachar teaches creating a service locator clone, and it would have been obvious to apply the 
teaching of Ben-Shachar because Ben-Shachar' s appending a cluster would perform another service 
locator instance when one service locator instance fails. 
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Applicants respectfully traverse the above rejection, Ben-Shachar, alone or in 
combination, does not teach or suggest all of the features of amended claim 1 . 

Applicants amended independent claims 1 and 15 to emphasize the transparent 
feature of the invention, specifically calling for the steps of, "establishing name service clusters for 
the object servers which each contain a unique object binding table that contains object server 
references [and] in response to a request from a client that invokes a cluster, performing a load 
balance by having the name service select an object server located in the invoked cluster." Since 
the name service is inherent in CORBA", "the fault tolerance, the load balance, and the failover are 
performed transparently" i.e., without modification to the network or its conrununication protocols. 
The applicant submits that the term transparent is defined as invisible to the user. The applicant 
attaches a copy of the definition of "transparency" and "transparent" from Newton's Telecom 
Dictionary, 18^^ Edition, CMP Books ^ 2002, page 763. "Transparency" is defined there as the 
"transportation of information invisible to the user" and "transparent" as a "feature ... the user ... is 
totally unaware that it exists." Additionally, Ben-Shachar itself uses the term transparent to 
indicate invisibility to a user. (See Col. 2, 11. 18-19; Col. 1 1 11. 62-63). 

Under claims 1, 9 and 15 the fault tolerance, load balance and failover occur 
transparently through the use of the CORBA name service. Specifically there are no changes in 
communication pattems or services, and there are no changes in user, client or server codes. Simply 
stated, transparency under claim 1 is achieved by embedding the fimctionality of fault tolerance, 
load balance and failover into the existing name service of the CORBA communication pattem, and 
performing those fimctions within the constraints of that communication pattem. 

In contrast, Ben-Shachar does not embed fimctionality of performing the fault 
tolerance, load balance and failover into an existing communication pattem but instead builds a 
system on top of the existing CORBA infrastructvu-e. This technique creates noticeable changes to a 
user, and therefore the fault tolerance, load balance and failover are not performed transparently. 
For instance, to enable load balancing and fault tolerance, Ben-Shachar requires infrastructure and 
services above and beyond the standard CORBA infrastructure. Specifically, Service Locator and 
Service Manager must be nmning to enable the two fimctions. As an example, Ben-Shachar 
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requires that a service proxy be included in the client (Fig. 3). For each new server type that client 
wants to talk to, a service proxy for that type must be generated on the client end. Essentially part 
of load balance logic actually lies on the client end in Ben-Shachar's solution. Also clients doing 
dynamic invocation on the server object will bypass the service proxy completely and will be cut 
out of Ben-Shachar s solution. 

As admitted by the Examiner with respect to claim 14, Ben-Shachar's system does 
not include an "object binding table" as now recited in claims 1 and 15. 

Further, the system of Ben-Shachar requires that the Server (which he calls Worker) 
be launched when necessary by Service object. This may require some modification in the server 
and some setup to make infrastructure aware of where the server resides. The present invention 
makes no demands on the server at all. The name service needs to know nothing about where the 
server is running. 

In addition the system of Ben-Shachar requires additional infrastructure such as 
Service Locator, Service Manger, and etc. to enable load balancing. These are above and beyond 
what a normal CORBA infrastructure requires and do not correspond to the name service of 
CORBA, the system of Ben-Shachar is in operation in a CORBA environment and requires these 
additional units. In contrast, the present invention just requires the CORBA Name Service, which is 
a standard CORBA infi-astructure that most customers are already using. 

Ben-Shachar's system requires participants to change their existing communication 
patterns to enable load balancing. Instead of client talking to the name service to obtain an object 
reference of the server as is the norm, a client using the Ben-Shachar system must talk to a service 
locator, create a service, allocate a worker (server) and then obtain that server. The present 
invention does not impose the requirement that the client or server change any of their existing 
communication patterns. 

The Examiner cites Col. 11, lines 1-6 and lines 12-17 to demonstrate that Ben- 
Shachar discloses creation of a naming service to perform load balancing within clusters. At lines 
1-6 the only description is of the findService which returns the names of servers that can perform 
the function. Even then, this function is in the service locator, which is an element that must be 
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added to the system. Lines 12-17 describe a second level of load balance in which the service 
locator obtains statistics from all the services and provides the handle (name) of the least busy. 
However, again this is a separate piece of equipment that must be added to and accommodated in 
the Ben-Shachar system. It is not the existing name service of COBRA. 

Moreover, Ben-Shachar may be classified as prior art, previously described in the 
Specification, at page 2, lines 14-25. Ben-Shachar's solution to load balancing and fault tolerance is 
best described as intrusive, not transparent, because it requires building a system or changing a 
system to make it load balance and fault tolerance aware. The service proxy, service locator, service 
object and worker all cooperate with one another as part of a close knit framework, thus making it 
impossible to perform a load balance or fault tolerance where a CORBA client and a CORBA server 
are both unaware of the framework. Since the entire system must be built based on the framework 
Ben-Shachar established, load balancing and fault tolerance are not performed transparently. 

Based on the aforementioned, Ben-Shachar alone or in combination does not teach or 
suggest performing the fault tolerance, load balancing or failover in a transparent manner using the 
CORBA name service, and therefore does not render present claims 1, 9 and 15 unpatentable. 

In rejecting claim 2 the Examiner also relies on the Ben-Shachar reference in 
combination with the Java Reflective Broker reference (JR), which was cited to show the use of a 
port number and IP address. While, claim 2 uses the BP address and port number to bind a server to 
a chent (See the Application, page 7, line 21 to 24) and JR shows the same communications 
protocol, JR fails to provide what is missing from Ben-Shachar, i.e., using the name service of 
COBRA to support load balancing, etc. 

Claims 10, 12 and 13 were rejected on the Ben-Shachar reference in combination 
with the Arno patent, where the Amo patent was cited to show Round robin load balancing. 
However, like the JR reference, Amo fails to provide what is missing from Ben-Shachar, i.e., using 
the name service of COBRA to support load balancing. The Examiner cites the Geoffrey reference 
against claims 14, which specifically calls for the "binding table." This element has also been 
introduced into claims 1 and 15. However, Geoffrey merely discloses that such tables are common 
in CORBA, and fails to disclose its use for load balancing or failover. 
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Claim 16 was rejected on the Ben-Shachar reference in combination with the patent 
to Nelson, where Nelson was cited to show a configuration file. Claims 17 was rejected based on 
Ben-Shachar, the patent to Rawson, the patent to Nelson and the JR reference, where Rawson was 
cited to show a flag to activate implicit clustering. Claims 18 and 19 were rejected based on Ben- 
Shachar, the patent to Rawson, the patent to Nelson and the Amo patent. Claims 20 and 21 were 
rejected based on Ben-Shachar, the patent to Rawson, the patent to Nelson and a patent to Nessett, 
which was cited to show the clustering together of object reference bindings having identical names. 
While each of these may show some minor enhancement, none of the disclose or render obvious the 
main features of the invention as set forth in claims 1 and IS. 

There does not appear to be any specific rejection of claim 22, which is directed to 
Smart Round Robin load balancing, based on prior art. 

Newly added claims 23 and 24 are patentable for the same reasons as claims 1 and 

15. 

Conclusion 

Each and every point raised in the Office Action dated February 9, 2005 has been 
addressed on the basis of the above amendments and remarks. In view of the foregoing it is 
believed that claims 1-24 are in condition for allowance and it is respectfully requested that the 
application be reconsidered and that all pending claims be allowed and the case passed to issue. 
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If there are any other issues remaining which the Examiner believes could be resolved 
through a Supplemental Response or an Examiner's Amendment, the Examiner is respectfully 
requested to contact the undersigned at the telephone number indicated below. 



Dated: June 3, 2005 Respectfully submitted, 

Melvin C. Gamer 

Registration No.: 26,272 
DARBY & DARBY P.C. 
P.O. Box 5257 

New York, New York 10150-5257 
(212) 527-7700 

(212) 527-7701 (Fax) 
Attorneys/ Agents For Applicant 
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